Electronic printing systems include an input section, sometimes referred to as an input image terminal (“IIT”), a controller, sometimes referred to as an electronic subsystem (“ESS”) and an output section or print engine, sometimes referred to as an image output terminal (“IOT”). In one type of electronic printing system, manufactured by Xerox known as the DocuTech electronic publishing system (“DocuTech” is a registered trademark of Xerox Corporation), a job can be inputted to the IIT from, among other sources, a network or a scanner. An example of an IIT with both network and scanner inputs is found in U.S. Pat. No. 5,170,340 to Prokop et al. (Issued: Dec. 8, 1992).
When a scanner is employed to generate the job (in the context of, for example, a digital copier), image-bearing documents are scanned so that the images therein are converted to image data for use in making prints. When a network is used to generate the job, a stream of data, including various job related instructions and image data, expressed in terms of a page description language is captured, decomposed and stored for printing. As is known, a network job can have its origin in a remote client, such as a workstation, or a print server with a storage device.
Electronic printing systems, sometimes also called “electronic reprographic systems”, are advantageous in that they can be coupled with other components, by way of a network, to facilitate image processing operations among the components. An example of a network printing arrangement including a wide range of image processing capability can be found in U.S. Pat. No. 5,113,494 to Menendez et al. (Issued: May 12, 1992).
As borne out by U.S. Pat. No. 5,113,494, a significant amount of control for a network printing system resides in one or more network servers. The following patents disclose examples of systems including servers: U.S. Pat. No. 5,220,674 to Morgan et al. (Issued: Jun. 15, 1993) and U.S. Pat. No. 5,243,518 to Holt et al. (Issued: Sep. 7, 1993). Brief discussions of U.S. Patent Nos. 5,113,494; 5,220,674; and 5,243,518 are provided in U.S. Pat. No. 5,872,569 to Salgado et al. (Issued: Feb. 16, 1999). U.S. Pat. No. 5,243,518 is particularly noteworthy to the area of electronic printing in that it discloses a layered document services architecture facilitating operation and interconnection of electronic printing systems with both resident and non-resident work inputs.
Programming a job is often achieved with a “job ticket”. For many printing systems, the job ticket is provided in the form of one or more programmable dialogs, each programmable dialog including values which are selected with a user interface, such as the user interface found in a DocuTech (“DocuTech” is a registered trademark of Xerox Corporation) printing system. Job tickets can vary dramatically in both structure and functionality. In one instance, the job ticket may assume the form of a relatively simple dialog displayed on a liquid crystal display (“LCD”). Attributes of a corresponding job, such as desired image processing, designated stock and finishing characteristics may be displayed for setting of suitable output values, e.g., stock size.
Disclosures of relatively complex job ticketing approaches are provided by way of the following patents:
U.S. Pat. No. 5,079,723 to Herceg et al. (Issued: Jan. 7, 1992)
U.S. Pat. No. 5,260,805 to Barrett (Issued: Nov. 9, 1993)
U.S. Pat. No. 5,398,289 to Rourke et al. (Issued: Mar. 14, 1995)
U.S. Pat. No. 5,450,571 to Rosekrans et al (Issued: Sep. 12, 1995)
U.S. Pat. No. 5,600,762 to Salgado et al. (Issued: Feb. 4, 1997)
The patents listed above are discussed in U.S. Pat. No. 5,872,569 to Salgado et al. Other patents providing further background in the area of user interface design include:
U.S. Pat. No. 5,513,126 to Harkins et al. (Issued: Apr. 30, 1996)
U.S. Pat. No. 5,718,520 to Mackay (Issued: Feb. 17, 1998)
U.S. Pat. No. 5,872,569 to Salgado et al. is directed toward a system, with a screen display, and an application server, is provided. Preferably, the application server registers one of a plurality of metaphor elements with a set of device attributes. A status indicating metaphor or a control metaphor is developed for use with the one of the plurality of metaphor elements. When displaying a metaphorical template, including the one of the plurality of metaphors on the screen display, the status indicating or control metaphor is associated with the one of the plurality of metaphor elements for facilitating the programming of a job or controlling an output of the job.
U.S. Pat. No. 5,513,126 Harkins et al. is directed toward a method for a sender to automatically distribute information to a receiver on a network using devices (such as printers and facsimile machines) and communication channels (such as electronic mail) defined in a receiver profile. The receiver profile establishes the properties and mode for receipt of information for receivers on the network and the profile is published in a network repository for all network users or is accessible by selected groups or individuals on the network. Receivers have additional control over network senders by defining an information filter which further controls sender channel access (to a receiver) by defining some channels as having priority of access such as direct or delayed access, as well as selectively permitting senders to override the receiver profile. Consequently, receiver profiles provide a variable receiver definable link to senders using multiple forms of media as well as multiple hardware platforms and network configurations.
U.S. Pat. No. 5,718,520 to Mackay is directed toward an apparatus for automatically modifying a print job ticket having a plurality of page tickets is provided. Each page ticket is programmed with one or more print job attributes and each print job attribute is associated with one or more print job characteristics. In practice, one or more values are assigned respectively to the one or print job characteristics. The print job attributes and print job characteristics are stored in memory as a set, and a portion of the set is scanned with a processor to determine each page ticket upon which a print job characteristic first value is located. A set of page tickets is selected from the page ticket(s) determined with the processor and, for at least a portion of the set of page tickets, one or more print job characteristic first values are changed to print job characteristic second values so that the need on the part of a printing system user to manually change print job characteristic first values to print job characteristic second values is minimized.
As is known, job tickets can also be provided in hardcopy form. A discussion of “paper UI” is provided in U.S. Pat. No. 5,243,381 to Hube et al. (Issued: Sep. 7, 1993). In accordance with U.S. Pat. No. 5,243,381, a link to a job ticket is provided through a “separator sheet” upon which one or more bar codes are printed. In practice, when an image capture device, such as a scanner, reads the bar code, a corresponding pre-stored set of job programming instructions is retrieved from memory for use in processing a job.
In the context of print job production, it is understood that the following problem or publishing need can arise:
Users often need to print a single piece of information (a document) more than one way, essentially producing multiple different physical forms of a document. For example a lecturer, about to give a presentation, may desire to print his or her presentation in the following ways (or job types):                50 stapled, duplex sets w/covers to use as handouts        1 simplex set of overhead transparencies for the actual presentation        1 simplex set of punched paper (for the presenter to keep notes on)        
It is understood that, in a significant number of currently available digital printers/copiers, this presentation would be processed by submitting a single file, expressed in a conventional page description language (“PDL”) multiple times to a printer, where a different “job ticket” is provided for each way. The presentation is to be printed or rendered. To the printer, these jobs appear to be distinct jobs and are processed totally independent of each other. Obviously, submitting PDL across a network to the Print Server multiple times is inefficient.
A few products, such as DocuTech with its DocuSP controller (“DocuTech” and “DocuSP” are trademarks of Xerox Corporation), solve the problem of multiple PDL submissions by allowing a user to SAVE a job, with its associated first job ticket, on a print server. The job data is then referenced by a pointer in subsequent job submissions containing just new job tickets. That is, each new job ticket is referenced (one-at-a-time) to a print ready file. Job Tickets can also be saved and later retrieved for application to a particular job.
While saving jobs and tickets, in the manner described above, goes a long way toward addressing the perceived problem (i.e. the problem of printing a presentation of multiple job types in multiple submissions), one further problem remains: How can all job tickets applicable to a job be logically related to the job, and the resulting relationship be maintained over time?
By way of the above-mentioned U.S. Pat. No. 5,600,762 to Salgado et al., it is known that a print job, may be a “composite job” where, the composite job is really nothing more than the packaging of multiple individual job segments into a singular entity that is printed together in some determined quantity. In this case, each job segment consists of its own page images (usually in PDL form) and an associated “segment” ticket. These segments are concatenated together and processed by the printer to produce a collection of documents that are somehow related.
The approach of U.S. Pat. No. 5,600,762 to Salgado et al. may be used to print what are known as “course packs”. An example of a course pack might include a job where the first segment of the job is an instruction sheet on green paper to be read by the student, the second segment is a set of readings the student is directed to read, and the third segment is a test to be taken after the student has read the material. Usually, for these composite jobs, some job ticket parameters, such as print quantity, are best applied globally and must be placed in a global ticket, whereas other job ticket parameters, such as media, are best applied within the individual segment tickets.
This approach, however, is believed to fall short of addressing the publishing need identified above. To produce the multiple forms of the presentation in the example posed immediately above, the page images would, at least in some instances, have to be repeated in each of the segments—that could be wasteful—and the global programming could cause some problems (e.g. produce the same quantity of overheads as handouts).
“Interpress”, a Xerox developed PDL, addressed the above-identified publishing need through use of a programming instruction known as “IFCOPY”. IFCOPY is intended to allow certain copies within a multi-copy job to be rendered with alternate programming (e.g. copies 1-3 on white paper and copy 4 on blue paper). However, there appear to be several problems with using this approach in the context of print job programming:
First, the IFCOPY instruction is coded deep within an Interpress master (possibly at multiple page locations) and cannot be easily changed once the PDL file (with its corresponding programming) is created. To use the IFCOPY functionality in a manner similar to a job ticket, a user would be required to parse the PDL file, locate relevant programming or instruction(s), replace it with an alternate instruction(s), and rebuild the master. This is hardly the type of programming that would be suitable for use in a typical printing arrangement.
Second, its effective use would also require that the PDL language itself be capable of specifying all the printing instructions necessary to produce a job. However, because many complex job ticket instructions are often device dependent and not associated directly with image rendering, they are often not considered appropriate instructions for inclusion in the PDL, and thus do not exist in the PDL.
In view of the above, it would be desirable to provide a system (with suitable attendant process) in which multiple job tickets can be programmed for a single submission to a printer, along with one corresponding set of image data, to yield multiple job renderings. Moreover, it would be desirable to provide a convenient vehicle for storing the tickets together with the image data so that the programming for the multiple job renderings can be readily manipulated or edited.
All of the disclosures for the patents referenced in the above Background are incorporated herein by reference.